home *** CD-ROM | disk | FTP | other *** search
- Path: news.eunet.fi!fipnet!kone!jsaarinen
- Newsgroups: comp.sys.amiga.programmer
- X-NewsReader: IntuiNews 1.2b (31.7.94)
- References: <4d42gg$i2p@ra.ibr.cs.tu-bs.de> <4dov8s$rc5@ar.ar.com.au>
- From: "Jyrki Saarinen" <jsaarinen@kone.fipnet.fi>
- Date: Tue, 23 Jan 96 15:56:14 UT
- Comments: Illegal date header - new date added by quicknews
- X-Original-Date: Tue, 23 Jan 96 00:16:44
- MIME-Version: 1.0
- Content-Type: text/plain; charset=iso-8859-1
- Content-Transfer-Encoding: binary
- Distribution: world
- Subject: Re: PPC compilers
- Message-ID: <38232132@kone.fipnet.fi>
-
-
- > To do fast 16:16 bit fixed point maths (ie for bitmap scaling). You have
- > the fraction in the high word and the integer part in the low word.
- >áBecause of the addx, every time the fraction wraps around, the X bit is set
- >áand next add, the integer bit is incremented.
-
- Addx is really great .. Hmm. We could think of all the
- situations where addx could possibly go wrong. (I mean
- fixed point interpolations)
-
- At least this has to be done before the loop:
- moveq #0,d0
- add.l d1,d0
-
- ...
- .loop addx.l d1,d2
- dbf d7,.loop
-
- But what about if there is two addx? Theis decimal parts
- have to be switched, which is done nicely with eor
- before swapping, but what about that before loop
- correction? Of course this perfect accuracy
- is not required on 16.16 fixed point but if
- there is a smaller amount of fraction, the
- errors can be quite big..
-
- -- _
- a Stellar programmer _ //
- "Amiga - back for the future" \X/
-